JavaScript: how NPM maintainer accounts amplify risk

20 compromised JavaScript package “maintainer” accounts — that’s all it takes to bring down the global digital supply chain through malicious code executed in the browser.

Attackers need to target only 20 specific maintainer accounts to reach more than half of the entire JavaScript npm ecosystem, security researchers warn. With regular browsers on the receiving end, ready to indiscriminately execute code from affected web pages, this can trigger a disastrous chain reaction.

More than 800,000 free and reusable software packages are available through the npm (“node package manager”) software package registry. Should an attacker breach one of these at-risk accounts, it could bring down the digital supply chain worldwide, the findings of the Technical University of Darmstadt (TU Darmstadt) in Germany indicate.

In their report for Usenix, Small World with High Risks: A Study of Security Threats in the npm Ecosystem, Markus Zimmermann, Cristian-Alexandru Staicu, Cam Tenny, and Michael Pradel shine a light on the widespread use of npm packages throughout the internet and the implications for cybersecurity. In their paper, they highlight the immediate and deleterious effect that malicious changes to this underlying software would have.

When attackers can compromise one or more of the code elements of a solution before that solution is executed, this action causes the resultant output to be faulty, crippling the individual computer or whole networks and/or causing data breaches.

The TU Darmstadt team puts it this way:

“[A] very small number of maintainer accounts could be used to inject malicious code into the majority of all packages, a problem that has been increasing over time.”

“Very small” cause. Maximum damage.

This threat exists because JavaScript doesn’t provide any kind of privilege separation between code loaded from different packages. As a result, any third-party package inherits the full privileges of the entire application.

A threat action could be caused by a package that, without its developer’s knowledge, is running vulnerable or malicious code introduced by the third-party dependencies bound to the same package.

Another finding of the TU Darmstadt team illustrates that this risk isn’t just a theoretical possibility. 40% of all npm packages, the authors point out, rely on code that is known to be vulnerable.

“When installing an average npm package, a user implicitly trusts around 80 other packages due to transitive dependencies.”

How NPM interdependencies multiply threats

The TU Darmstadt team references related research of remote inclusion of JavaScript libraries used by the 10,000 most popular websites. An average site adds between 1.5 and 2 new dependencies per year.

A popular package can reach more than 100,000 other packages by being used directly by a developer or being used by a program which is then used by the developer, making such shrink-wrapped code a prime potential target for attacks.

This means that a missing package can trigger a whole chain reaction. It also means exponentially increased risk through malicious JavaScript for the affected sites and for users who access them with a conventional browser, which will indiscriminately process such code locally.

For example, in March 2016, a small utility package called left-pad was removed from the npm ecosystem. This, in turn, caused a large percentage of packages to become unavailable because they directly or indirectly depended on left-pad.

In July 2018, compromising the credentials of the maintainer of the popular eslint-scope package enabled an attacker to release a malicious version of the package, which - once installed - tried to send local files to a remote server.

Target and Gateway: The Local Browser

As the primary online tool in business, the traditional browser is not only the most widely used piece of web-facing software. Its tight integration with the operating system and local resources also makes it the gateway for at least 70% of cyberattacks.

That includes attacks on the software supply chain, which have increased in frequency over the past years. One prominent example was an attack against British Airways that resulted in a record fine levied against the company under the European Union’s General Data Protection Regulation (GDPR) by UK authorities.

Due to JavaScript’s ubiquity in today’s web scrape, any malicious change in the code of a site or web app (no matter where it originates) will affect the web-browsing client of the site’s managers, visitors or app users.

What actions exploited third-party JavaScript code attempts to perform in the browser depends on the attacker’s goals. Downloading and installing a ransomware exploit kit on the target machine is common, as is cryptojacking (having browsers mine cryptocurrency in the background).

Another real-life example are watering hole attacks. Web visitors get profiled for pinpointed targeting of government or financial institutions. Take your pick.

How Third, Fourth, Fifth Party Risks Threaten Compliance

Let’s face it: third-party suppliers are a security liability for the enterprise because they can unintentionally open the door for code infiltration and data exfiltration.

Yet for modern businesses, forfeiting the competitive advantages of using third parties by going it alone is not an option.

This puts especially tightly regulated industries between a rock and a hard place. In a 2019 survey, Gartner found 80% of legal and compliance leaders state that third parties (such as startups and business model innovators) - rather than incumbent service providers - provide new-in-kind technology services for organizations.

The same survey shines a light on how the attack surface for such exploits is widening. Gartner found that 83% of organizations still uncovered third-party risks after they had conducted due diligence.

Would you be surprised to learn that more than half of the respondents said they rely on trust alone to evaluate third-party security? And get ready for more bad news - the Gartner findings also indicate that the problem will likely not get solved from within the supply chain, by the vendors themselves.

Inhouse lawyers and compliance managers reported that the third parties they oversee are working with an increasing number of their own third parties (fourth and fifth parties).

As a consequence, the potential victims are bearing the burden of preventing data breaches caused by npm maintainer account exploits and other means. How can IT shield the organization

What Can IT and Compliance Managers Do?

Best practices in preparing for this kind of attack include:

• Establishing a standard baseline security posture for the enterprise that applies to internal areas and third parties alike; this means that all parts of the enterprise have to look at these security areas when vendor choices are to be made.

• Writing the policies down in a canonical always-available form (not just an email); this ensures that policies are disseminated across the enterprise with all content intact.

• Verifying the policies in practice; the enterprise needs proper documentation of compliance with the requirements of PCI, HIPAA, and location-dependent security policies such as GDPR.

As part of this verification, a diagram of data flow can prove useful. The enterprise will be held accountable by regulators for where and how data is generated (and stored). Third parties must be able to show (and know) where an enterprise/supplier data mix is flowing to show their compliance.

Granted, you can write anything on paper (or in an email). So trust (but verify) that what you assume is happening on the vendor’s side is indeed demonstrably occurring.

And above all, keep in mind that the ultimate targets of most supply chain attacks, including such leveraging npm maintenance accounts, are your organization or its customers’ local web browsers.

That means that functional isolation of all web activities outside your organization’s IT perimeter may be the only effective path to prevent and disincentivize generalized digital supply chain attacks in the future.

Web isolation precludes code from the internet from being processed by locally installed browsers. Instead, it provides users with a visual display stream (benign pixels, essentially) of the web session from a secure container in the cloud.

Because any browsing activity and web application usage occur in isolation offsite, no code can touch the endpoint and infect your local network.

No matter if one, twenty, or more of npm maintainer accounts have been compromised - it’s not your worry anymore.

This blog was written by guest contributor Larry Loeb.

Larry Loeb has been online since uucp "bang" addressing (where the world existed relative to !decvax) and served as editor of the Macintosh Exchange on BIX and the VARBusiness Exchange. He wrote for BYTE magazine, was a senior editor for the launch of WebWeek, and authored books on the Secure Electronic Transaction Internet protocol and "Hack Proofing XML" (his latest). Larry currently writes about cybersecurity for Security Now.